Virtual connection route selection apparatus and techniques

ABSTRACT

Virtual connection route selection apparatus and techniques are disclosed. At a communication traffic routing apparatus, metric information associated with multiple different routes for a virtual connection, such as a PseudoWire, toward a destination is collected. The metric information may be collected from one or more remote route computation elements capable of computing routes for virtual connections between the routing apparatus and other routing apparatus over an underlying communication system, or during actual establishment of the virtual connections, for example. An initial or re-optimized route for a virtual connection can then be selected at the routing apparatus based on the collected metric information. In some embodiments, although the virtual connection routes are paths computed by Path Computation Elements (PCEs), actual path selection decisions are distributed to routers.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.11/679,582 filed on Feb. 27, 2007.

The entire contents of this related patent application are incorporatedin their entirety herein by reference.

FIELD OF THE INVENTION

This invention relates generally to communications and, in particular,to selecting between routes for virtual connections over an underlyingcommunication system.

BACKGROUND

There are many circumstances in which a head end or source router cannotaccurately determine the end-to-end cost and/or possibly other metricsassociated with a path that is used to establish an end-to-endPseudoWire (PW). This is especially true for Multi-Segment PWs (MS-PWs)or for PWs spanning multiple operational or administrative domains suchas routing domains. Although a head-end router might attempt to find thebest path based on its local information, there is no guarantee that theestablished path is optimal with respect to the above mentioned metrics.There are currently no mechanisms for re-optimizing virtual connectionssuch as end-to-end PWs based on the total end-to-end cost discovered.

In Asynchronous Transfer Mode (ATM) systems, a Domain Based Reroutingfeature together with other signalling capabilities of PrivateNetwork-Network Interface (PNNI) specifications has been used to collecta total cost of a head-end routed connection, to establish alternativeconnections, and then to move one connection into another, potentiallyoptimizing the end-to-end cost. This particular feature, however, iscurrently limited to ATM, and is also not applicable to communicationsystems in which centralized path computation is deployed, for example.

In Internet Protocol (IP) networks, external systems are typicallyrequired to re-optimize paths. However, these external systems likelyhave a limitation of working within a single administrative boundaryonly, as security concerns tend to prevent network operators fromsharing their network topology information so as to allow effectiveend-to-end optimization.

Thus, there remains a need for improved techniques relating tooptimization of, and more generally selection between multiple availablepaths or routes for, virtual connections such as PWs.

SUMMARY OF THE INVENTION

Some embodiments of the invention provide a mechanism to dynamicallyoptimize PWs based on collected metrics such as end-to-end cost.

According to one aspect of the invention, a communication trafficrouting apparatus includes a metric information collector operable tocollect, from metric information generated by at least one remote routecomputation element that is capable of computing routes for virtualconnections between the routing apparatus and other routing apparatusover an underlying communication system, metric information associatedwith a plurality of different computed routes for a virtual connectiontoward a destination, and a selection module operatively coupled to themetric information collector and operable to select, from the differentcomputed routes, based on the collected metric information, a route fora virtual connection toward the destination.

The routing apparatus may also include an interface operatively coupledto the metric information collector and operable to enable the routingapparatus to communicate with the at least one remote route computationelement, in which case the metric information collector may collectmetric information by receiving the metric information from the at leastone remote route computation element through the interface.

The metric information collector may also receive through the interface,from any of the at least one remote route computation element,information indicative of each of the different computed routes.

Each remote route computation element may be a Path Computation Element(PCE) for computing Label Switched Paths (LSPs) in some embodiments. Themetric information collector may then include a Path Computation Client(PCC).

The selection module may be operable to select a route for a virtualconnection for initially establishing communication traffic transferbetween the routing apparatus and the destination.

In some embodiments, the different computed routes include a currentlyselected route for a virtual connection that has been established towardthe destination, and the selection module is operable to select eitherthe currently selected route or another one of the different computedroutes for a virtual connection for subsequently exchangingcommunication traffic with the destination, based on the collectedmetric information respectively associated with the different computedroutes.

The virtual connections may be PWs, for instance.

In some embodiments, at least one of the virtual connections comprises amulti-segment virtual connection having a plurality of segments.

The metric information associated with each computed route of theplurality of different computed routes may include informationindicative of at least one of: a route cost, cumulative delay to reachthe destination from the routing apparatus over each computed route, andan amount of available bandwidth on each computed route afterestablishing the virtual connection over the computed route.

A method is also provided, and involves collecting at a routingapparatus, from metric information generated by at least one remoteroute computation element that is capable of computing routes forvirtual connections between the routing apparatus and other routingapparatus over an underlying communication system, metric informationassociated with a plurality of different computed routes for a virtualconnection toward a destination, and selecting at the routing apparatus,from the different computed routes, based on the collected metricinformation, a route for a virtual connection toward the destination.

The operation of collecting may involve receiving the metric informationfrom the at least one remote route computation element.

As noted above, each remote route computation element may be a PCE forcomputing LSPs. In this case, receiving may involve receiving the metricinformation at a PCC of the routing apparatus.

In some embodiments, selecting involves selecting a route for a virtualconnection for initially establishing communication traffic transferbetween the routing apparatus and the destination.

Where the different computed routes comprise a currently selected routefor a virtual connection that has been established toward thedestination, selecting may involve selecting either the currentlyselected route or another one of the different computed routes forsubsequently exchanging communication traffic with the destination,based on the collected metric information respectively associated withthe different computed routes.

The metric information used in such a method may include informationindicative of at least one of: a route cost, cumulative delay to reachthe destination from the routing apparatus over each computed route, andan amount of available bandwidth on each computed route afterestablishing the virtual connection over the computed route.

A method may be implemented, for example, in the form of instructionsstored on a computer-readable medium.

A communication traffic routing apparatus according to another aspect ofthe invention includes a metric information collector operable tocollect metric information respectively associated with a plurality ofdifferent routes over which PWs for exchanging communication trafficbetween the routing apparatus and a destination can be established, thedifferent PW routes comprising a currently selected PW route for a PWthat has been established toward the destination, and a selection moduleoperatively coupled to the metric information collector and operable toselect either the currently selected PW route or another one of thedifferent PW routes for a PW for subsequently exchanging communicationtraffic with the destination, the selection module selecting a PW routefor a PW for subsequently exchanging communication traffic with thedestination based on the metric information respectively associated withthe plurality of different PW routes.

The routing apparatus may also include an interface operatively coupledto the metric information collector and operable to enable the metricinformation collector to communicate with a remote route computationelement, the remote route computation element being capable of computinga PW route of the plurality of different PW routes, in which case themetric information collector may be operable to collect metricinformation by receiving through the interface, from the remote routecomputation element, metric information associated with the PW routethat the remote route computation element is capable of computing.

In some embodiments, the routing apparatus also includes a routingmodule operatively coupled to the metric information collector andoperable to cause any of the PWs to be established. The metricinformation collector may then be further operable to collect metricinformation associated with a PW route of each of the PWs duringestablishment of the PWs. The routing module may be further operable tocause each established PW having a PW route other than the PW routeselected by the selection module for subsequently exchangingcommunication traffic with the destination to be released.

In a case where each of the PWs is established through controlsignalling, the metric information collector may be operable to collect,from the control signalling, the metric information associated with thePW route of each of the PWs.

A further aspect of the invention provides a method that involvescollecting at a routing apparatus metric information respectivelyassociated with a plurality of different routes over which PWs forexchanging communication traffic between the routing apparatus and adestination can be established, the different PW routes comprising acurrently selected PW route for a PW that has been established towardthe destination, and selecting at the routing apparatus either thecurrently selected PW route or another one of the different PW routesfor a PW for subsequently exchanging communication traffic with thedestination, based on the metric information respectively associatedwith the plurality of different PW routes.

Collecting may involve receiving, from a remote route computationelement that is capable of computing a PW route of the plurality ofdifferent PW routes, metric information associated with the PW route.

The method may also include exchanging control signalling with otherrouting apparatus to establish at least one PW having a PW route otherthan the currently selected PW route, in which case collecting mayinvolve collecting, from the control signalling, metric informationassociated with the PW route of each of the at least one of the PWs.

Other aspects and features of embodiments of the present invention willbecome apparent to those ordinarily skilled in the art upon review ofthe following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments of the invention will now be described ingreater detail with reference to the accompanying drawings.

FIG. 1 is a block diagram of a communication system.

FIG. 2 is a block diagram of a collection of network elements in acommunication system.

FIG. 3 is a block diagram of a logical communication link topologyoverlay on the network elements of FIG. 2.

FIG. 4 is a block diagram of a routing apparatus.

FIG. 5 is a flow diagram of a method according to an embodiment of theinvention.

FIG. 6 is a block diagram of an example data structure for carryingmetric information in control signalling.

FIG. 7 is a block diagram of another example data structure fortransferring metric information to routing apparatus

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The description below refers to the following documents or thetechnologies disclosed therein:

-   Farrel, et al., “A Path Computation Element (PCE)-Based    Architecture”, Request For Comments (RFC)-4655, The Internet    Society, August 2006;-   Vasseur, et al., “Path Computation Element (PCE) communication    Protocol (PCEP)”, Internet-Draft, The IETF Trust, Feb. 13, 2007;-   Dolganow, et al., “A new object to specify a Traffic Engineering    (TE) Label Switch Path (LSP) cost”, Internet-Draft, The Internet    Society, October 2005.

The entire content of each of the above-referenced documents isincorporated herein by reference.

FIG. 1 is a block diagram of a communication system in which embodimentsof the invention may be implemented. The communication system 10includes several networks 14, 16, 18, 20, which may in some embodimentsbe different operational and/or administrative sub-domains within anadministrative boundary 12. For example, the networks 14, 16, could bemetro networks, the network 18 could be an access network, and thenetwork 20 could be a core network. Each of the networks 14, 16, 18, 20includes a route computation element 15, 17, 19, 21 in the exampleshown. Within an administrative boundary 12, a single route computationelement 22 might instead be used.

It should be appreciated that the system of FIG. 1, as well as thecontents of the other drawings, are intended solely for illustrativepurposes, and that the present invention is in no way limited to theparticular example embodiments explicitly shown in the drawings anddescribed herein.

For example, each of the networks 14, 16, 18, 20 could itself be adomain with separate administrative and/or operational boundaries. Thesemay be brought together with other domains or managed separately at thesingle AS level in an arrangement as shown in FIG. 1. A centralizedroute computation element 22, distributed route computation elements 15,17, 19, 21, or some combination thereof, might be feasible in this kindof arrangement. However, the present invention is in no way limited toembodiments in which networks, or more generally routing apparatusbetween which virtual connections can be established, are deployedwithin a single administrative boundary. This type of arrangement isshown in FIG. 1 solely to illustrate the possibility of centralized anddistributed route computation elements.

It should also be appreciated that distributed route computationelements such as 15, 17, 19, 21 need not necessarily benetwork-specific. Other types of routing domains than distinct networks,such as different Interior Gateway Protocol (IGP) areas, differentadministratively established sub-domains, or different ASs for instance,are also contemplated. Each routing domain might have one or more routecomputation elements that can compute internal routes. The same routecomputation elements, or possibly one or more different routecomputation elements, might be operative to compute routes through andbetween multiple domains.

References herein to route computation elements should be interpretedaccordingly.

Communication links within and between the networks 14, 16, 18, 20 maybe established through any of various techniques. Typically,communication links within each network 14, 16, 18, 20 can be createdstatically or dynamically, whereas links between those networks areoften statically configured by an operator using an NMS or some otherterminal. Virtual connections might be established between routingapparatus in the networks 14, 16, 18, 20, over any of various routesusing those underlying communication links. A virtual connection such asa PW, for example, might be established to allow certain kinds ofservices to be provided over connectionless communication networks. Avirtual connection behaves substantially as a direct physical connectionfrom the perspective of its endpoints, which can be important for sometypes of communication traffic transfers.

The route computation elements 15, 17, 19, 21, 22 compute routes forsuch virtual connections. In general, a route computation element willhave some realm within which it can compute optimal routes. The routecomputation element 15 might be able to compute optimal routes withinthe network 14, for instance, whereas the route computation element 22might be able to compute optimal routes between, and possibly alsowithin, the networks 14, 16, 18, 20 in the administrative boundary 12.

In some implementations, multiple route computation elements maycollaborate to compute optimal routes that span multiple routingdomains. When a virtual connection is to be established between a sourcerouting apparatus in the network 14 and a destination in the network 16through the network 18, for instance, the source routing apparatus mightforward a route computation request to the route computation element 15.Responsive to the request, the route computation element 15 itselfcomputes a route for a segment of the virtual connection from therouting apparatus to a border routing apparatus in the network 14, butrelies on the route computation elements 17, 19, to compute routesegments through the networks 16, 18. Route computation by the routecomputation elements 17, 19 might be requested by the source routingapparatus or by the route computation element 15. A computed route isreturned to the source routing apparatus, and the virtual connection canbe initiated by the source routing apparatus along the computed route.

Those skilled in the art will be familiar with such route computationelements as Path Computation Elements (PCEs), which are used to computeLabel Switched Paths (LSPs) for PWs, responsive to requests from PathComputation Clients (PCCs). A communication protocol that enablesinteraction between PCEs and Path Computation Clients (PCCs), andbetween PCEs for the purpose of multi-domain path computation, has beenproposed in the above-referenced PCEP Internet-Draft document. Thus, aPCE is an example of a route computation element, and accordingly a pathcomputed by a PCE is an example of a route.

The present invention is in no way limited to any particular types ofroute or path computation algorithms or elements, or to any specificcommunication systems or arrangements, and accordingly the communicationsystem 10 has been described briefly herein. Illustrative examples ofcommunication systems and their operation are described in furtherdetail below to the extent necessary to illustrate embodiments of theinvention.

FIG. 2 is a block diagram of a collection of network elements (NEs) 32,34, 36, 38, 40, 42, 44, 46, 48, 50, 52 in multiple routing domains of acommunication system 30. The routing domains are delineated in FIG. 2 bydashed lines, and a distributed PCE 53, 55, 57 is shown as an example ofa route computation element for each domain. A PCE 53, 55, 57 maycommunicate with any, and possibly all, NEs in its respective routingdomain through an NE-based PCC. Although only one PCC 33 has been shownin FIG. 2 to avoid overly complicating the drawing, a PCC may beprovided at each NE in the system 30. PCEs may also communicate witheach other and/or possibly with NEs in other routing domains. Thisinter-domain interaction enables a PCE in one routing domain to acceptand respond to path computation requests from PCEs or NEs in otherrouting domains when routes for virtual connections that span multiplerouting domains are to be computed, for instance.

Other components may be provided in a communication system, such ascomponents to support administrative, control, and management functions,for example, but have not been explicitly shown in FIG. 2, again toavoid overly complicating the drawing.

The domain that includes the NEs 32, 34, 36 and the domain that includesthe NEs 48, 50, 52 might be metro networks, and the other domain mightbe an access network, for example. In this case, one or more of the NEs38, 40, 42, 44, 46 may also be connected to NEs in a core network and/orother network (not shown). As noted above, however, other types ofrouting domains are also possible. Those domains may be defined in termsof different IGP areas or at a higher protocol level, as PW domains, forexample. The dashed lines shown in FIG. 2 should therefore not beinterpreted as indicating that domains must be defined by some sort ofphysical layer arrangement.

Interconnections between the NEs shown in FIG. 2 may include wired,wireless, or both wired and wireless communication links. The presentinvention is not restricted to any particular types of communicationlinks between NEs, or to any particular protocols or transfermechanisms. Embodiments of the invention might be particularly useful toestablish PWs to support higher-level services over connectionlessnetworks such as packet switched networks (PSNs), although thetechniques disclosed herein may be used in conjunction with any ofvarious underlying communication links, such as MultiProtocol LabelSwitching (MPLS) tunnels in an IP network, for example.

The NEs 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52 shown in FIG. 2 arerouters in one embodiment. Routers, especially in implementations suchas access and metro networks where large numbers of NEs are to bedeployed at as low a cost as possible, may employ only limited routingfunctionality to reduce cost and complexity. Communication links betweenrouters may be established statically or dynamically, independently bythe routers or under control of a management/control system such as anNMS.

PWs and other types of virtual connections may also be established,between NEs such as routers, over underlying communication links. Theunderlying communication links include at least physical layer links,and may also themselves include other logical communication links. Inone embodiment, the techniques disclosed herein are applied to PWs overunderlying MPLS tunnels in an IP network. Although a virtual connectionsuch as a PW behaves substantially as a fixed path from the point ofview of its endpoints, the actual transport path in an underlyingcommunication system over which virtual connection traffic istransferred is not necessarily fixed. A PW between endpoint routers, forexample, might be established over a connectionless network, in whichcase the actual transport path would not be fixed. References herein tovirtual connections should be interpreted accordingly.

FIG. 3 shows a logical communication link topology overlay on thenetwork elements of FIG. 2. The logical topology 60 includes ProviderEdge routers (PEs) 62, 64, 66, 68, 70, 72, 74, 76, 78. Each logicalcommunication link represents, in one embodiment, a Targeted LabelDistribution Protocol (T-LDP) session established between PEs for PWsignalling within each administrative/operational sub-domain and betweenthe sub-domains. The routers 62, 64, 76, 78 are Terminating PE routers(T-PEs) having associated attachments circuits for establishing MS-PWsfor connections to other equipment that is not part of the logicaltopology, such as customer premises equipment, an NE that is not capableof participating in the logical topology, equipment in anothercommunication network, etc. The routers 66, 68, 70, 72, 74 are SwitchingPE routers (S-PEs), which are capable of switching communication trafficbetween PW segments of an MS-PW. Although not explicitly shown in FIG.3, multiple routers may exist on a logical communication link betweentwo T-PE's, two S-PEs, or a T-PE and S-PE.

PCEs 73, 75, 77 are also shown, and, as indicated by the dashedconnections, can communicate with the PEs 62, 64, 66, 68, 70, 72, 74,76, 78, illustratively with PE-based PCCs. The PCEs 73, 75, 77 may alsocommunicate with each other and/or with PEs outside their respectiverouting domains for multi-domain route computation.

PE routers are shown in FIG. 3 as a representative example of a type ofrouting apparatus that might be used to implement the techniquesdisclosed herein. PCEs are also intended as an illustrative example of atype of route computation element. These examples are not in any wayintended to limit the scope of the present invention. For instance,although PE routers and PCEs are associated with particularcommunication protocols and particular types of virtual connections,embodiments of the invention are not limited to such protocols orvirtual connections. Those skilled in the art will be familiar with PErouters and PCEs, their operation, and the associated protocols andvirtual connections, and accordingly embodiments of the invention can beeffectively illustrated in the context of PE routers and PCEs. Based onthe illustrative example of PE routers and PCEs, those skilled in theart will be enabled to implement techniques disclosed herein inconjunction with other types of routing apparatus, protocols, andvirtual connections.

It will be apparent from a comparison of FIGS. 2 and 3 that not allrouters in a communication system need necessarily be capable ofparticipating in communications at the logical overlay level. Multiplerouters may exist on logical communication links between two T-PEs, twoS-PEs, or a T-PE and S-PE. An NE that is not itself logical link-capablemay thus be involved in transporting logical link control signalling andtraffic between logical link-capable NEs, but may only participate in alimited scope of logical link functions or not participate at all inlogical link functions such as actual processing of logical linksignalling or traffic. Considering the logical link between the S-PEs68, 72, for example, the NEs 40, 44, and 46 may all be involved intransporting logical link signalling and traffic. The NE 44 is not anS-PE, but might be a so-called intermediate P router in this example.Thus, although dashed connections are shown in FIG. 2 between the PCE53, 55, 57 and every NE in each routing domain, a PCE might not actuallycommunicate with every NE in its domain.

More generally, a logical topology might not exactly reflect thetopology of an underlying communication system. Suppose that the NEs 42,44 are also operatively coupled to other NEs (not shown). In this case,those other NEs will not be reachable through the logical topology 60,since the NEs 42, 44 are not part of the logical topology. Those otherNEs may, however, participate in forwarding of MS-PW traffic orforwarding of signalling/control traffic exchanged over logicalcommunication links.

The logical communication links shown in FIG. 3 can be used to establishvirtual connections for carrying communication traffic between PEs. Inan MPLS network, for example, a pair of PEs will establish a logicalcommunication link in the form of a T-LDP session to exchange PW labelsand thereby establish a PW over one or more underlying MPLS tunnelsbetween the PEs.

Although illustrative embodiments of the invention described in detailherein relate primarily to selecting routes for virtual connections inthe form of point-to-point (P2P), bi-directional MS-PWs, the presentinvention is not limited to P2P MS-PWs. It will be apparent to thoseskilled in art that other types of MS-PWs like point-to-multipoint,multipoint-to-point, multipoint-to-multipoint, and both uni- andbi-directional may be established using the techniques disclosed herein.Accordingly, references to virtual connections, and to PWs inparticular, should be interpreted to encompass at least these types ofPWs.

References to destinations and virtual connections toward destinationsshould also be interpreted in a non-limiting manner. A destination isintended to convey the notion of a far-end component with whichcommunication traffic is to be exchanged over a virtual connection, andis not intended to connote a direction of traffic flow on a virtualconnection. It should be noted that a destination may or may not be theendpoint of a virtual connection. For example, in the case of an AC of arouter as a destination, the router itself may be the endpoint of a PW,whereas the AC is the destination with which communication traffic is tobe exchanged using the PW.

A virtual connection toward a destination is intended to generallydescribe a virtual connection that forms at least part of a virtualconnection between a routing apparatus and a virtual connection endpointthat is associated with the destination. In the example of an MS-PW, anysegment of the MS-PW may be considered a virtual connection toward thedestination. Again, no connotation of direction of traffic flow isintended by references to a virtual connection toward a destination.

When a virtual connection is to be established toward a destination,illustratively from the T-PE 62 as a Source T-PE (ST-PE) toward an AC ofthe T-PE 78 as a Target T-PE (TT-PE), the ST-PE 62 may request a pathcomputation from the PCE 73. The PCE 73 can itself compute a path fromthe ST-PE 62 to the S-PE 66. Assuming that each PCE 73, 75, 77 does nothave sufficient information for computing a path in other domains,either the PCE 73 or the ST-PE 62 requests a path computation by the PCE75 for a portion of the virtual connection between the S-PE 66 and theS-PE 74. A path computation for the last portion of the virtualconnection is requested from the PCE 77 by the ST-PE 62 or by one of thePCEs 73, 75.

Each PCE returns a path computation response such as a reply message tothe component that requested the path computation, i.e., either theST-PE 62 or another PCE. The PCE 77 returns a path computation responseto either the ST-PE 62 or one of the PCEs 73, 75. Where the PCE 75receives the path computation result from the PCE 77, it may return tothe PCE 73 or the ST-PE 62 an overall path computation response for theportion of the virtual connection between the S-PE 66 and the T-PE 78.The PCE 73 may similarly return to the ST-PE 62 a path computationresponse for only a portion of the virtual connection within its routingdomain or the entire virtual connection.

As those skilled in the art will appreciate, a path computation responsefrom a PCE may include information that is indicative of one or morecomputed paths, where any paths that meet path computation criteriaspecified in the request could be found. A path computation response mayalso include other information, such as costs and/or other metricsassociated with each computed path. The additional information to beincluded in a path computation response might also be specified in apath computation request. A failure or other indication is returned inresponse to a request where no paths meeting the requirements specifiedin the request are found.

A PCE or other route computation element might not only compute routes,but also determine which of multiple computed routes is optimal. In manyimplementations, only the optimal route is returned as a routecomputation result. There are currently no defined mechanisms for arouting apparatus to make an optimal route determination based oninformation received from one or more route computation elements.

Embodiments of the invention relate to selection of routes for virtualconnections such as PWs. In some embodiments, end-to-end cost collectedthrough interaction with one or more PCEs as noted above, or throughother mechanisms such as during establishment of a virtual connectionalong a route, is used to record a cost of a virtual connection beingestablished along a route, to record a cost of an alternate route duringan optimization attempt for a virtual connection, and/or to re-optimizea virtual connection to a more optimal route.

More generally, metric information associated with different routes iscollected and used by a routing apparatus such as a router in makingdecision as to which route should be selected for a virtual connection.In this way, route selection decisions are distributed to routersinstead of being centralized at route computation elements or otherexternal systems.

These and other aspects of the present invention will be described infurther detail below.

FIG. 4 is a block diagram of a routing apparatus. In accordance with oneembodiment of the invention, a routing apparatus 80 includes a metricinformation collector 82, a memory 84 operatively coupled to the metricinformation collector for storing metric information and/or possiblyother information associated with virtual connection routes, one or moreone or more interface(s) 86 operatively coupled to the metricinformation collector, a routing module 87 operatively coupled to themetric information collector and to an interface, and a selection module88 operatively coupled to the memory and to the routing module.

A communication network routing apparatus may include other componentsin addition to those shown in FIG. 4. It should be appreciated that onlycomponents involved in metric information handling and virtualconnection functions have been explicitly shown in the routing apparatus80. It should also be appreciated that not all of the components shownin FIG. 4 need necessarily be provided in every embodiment of theinvention. Thus, the routing apparatus 80 is representative of oneillustrative embodiment of the invention. Other embodiments may beimplemented using further, fewer, or different components than shown inFIG. 4, with similar or different interconnections.

The types of connections through which the components of FIG. 4 areoperatively coupled may, to at least some extent, beimplementation-dependent. Communication equipment components often usevarious types of physical connectors and wired connections such asmidplane and backplane conductors, although the present invention is inno way limited to wired connections. In the case of cooperating softwarefunctions, for example, an operative coupling may be through variablesor registers, and thus be an indirect coupling rather than a directphysical coupling. Components may also be otherwise indirectlyphysically coupled together through other components.

The interface(s) component 86 represents one or more interfaces, andpossibly interfaces of multiple different types, that enable the routingapparatus 80 to communicate with other components of a communicationsystem. For example, the metric information collector 82 and the routingmodule 87 may interact with other communication system components toperform such functions as collecting metric information for virtualconnection routes and establishing virtual connections. Although only asingle interface(s) component 86 is shown in FIG. 4, the modules 82, 87need not necessarily be connected to the same interface or interfaces.

In general, the number and types of interfaces, and also theirconnection(s) to other components and to other routing apparatus, mayvary depending on the communication system and communication equipmentin conjunction with which the apparatus 80 is implemented. Those skilledin the art will be familiar with many such interfaces and theiroperation.

One or more memory devices may be used to implement the memory 84. Solidstate memory devices are common in communication equipment, althoughother types of memory devices, including devices for use with movable oreven removable storage media, may also or instead be used. Metricinformation is shown in FIG. 4 as an example of information that mightbe stored in the memory 84. It should be appreciated that metricinformation could be stored in one or more memory devices in the form inwhich it is collected and/or in a processed form. Other informationmight also be stored at a routing apparatus such as 80, in the memory 84or separately. Information indicative of routes for virtual connectionsbetween the routing apparatus 80 and various destinations, for example,could be stored as a routing table.

As described in further detail below, the metric information collector82 and the selection module 88 enable distributed selection of a route,at the routing apparatus 80, for a virtual connection based on metricinformation associated with multiple different routes for that virtualconnection. Metric information may be collected from metric informationgenerated by one or more route computation elements, during actualestablishment of virtual connections over different routes, or both.Based on the collected metric information, which may be accessed in thememory 84 or otherwise provided by the metric information collector 82,the selection module 88 can select a particular route for the virtualconnection, and the routing module 87 then causes the virtual connectionto be established over the selected route, if the connection has notalready been established.

At least the metric information collector 82, the routing module 87, andthe selection module 88 may be implemented using hardware, firmware,software for execution by one or more processing elements, or somecombination thereof. Any or all of devices such as microprocessors,microcontrollers, Programmable Logic Devices (PLDs), Field ProgrammableGate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs),Network Processors (NPs), and other types of “intelligent” integratedcircuits may be suitable for this purpose.

Given the many possible options for implementing the metric informationcollector 82 and the modules 87, 88, these components are describedherein primarily in terms of their functions. Based on the functionaldescriptions, a person skilled in the art will be enabled to implementtechniques according to embodiments of the invention in any of variousways.

The metric information collector 82 is operable to collect metricinformation associated with a plurality of different routes for avirtual connection toward a destination. In one embodiment, route metricinformation is collected from metric information that has been generatedby a remote route computation element that is capable of computingroutes for virtual connections between the routing apparatus 80 andvarious destinations, but is not itself part of or co-located with therouting apparatus. More than one route computation element may beinvolved in this process, for example, where a multi-segment virtualconnection spans several routing domains that have respective routecomputation elements.

Any of various mechanisms may be provided to support metric informationcollection. In a PCE-based system, for example, the metric informationcollector 82 may interact directly with a PCE, or possibly with severalPCEs, through an interface 86. Suppose that the routing module 87 oranother component of the routing apparatus 80 receives a connectionrequest for a virtual connection to a particular destination. Therouting module 87 might then send a command or request to the metricinformation collector 82, which in turn requests from one or more PCEs apath computation for a virtual connection toward the destination.

It should be noted that this process could also involve the selectionmodule 88 as well. For example, the routing module 87 could request aroute for the virtual connection toward the destination from theselection module 88, which then, through another command or request forinstance, causes the metric information collector 82 to request a pathcomputation for the virtual connection from one or more PCEs through aninterface 86. In either of these scenarios, the metric informationcollector 82 receives metric information for computed paths from thePCE(s) through an interface 86.

Another possible metric information collection mechanism might involvemore passive operation by the metric information collector 82. Forexample, where a separate PCC is provided at the routing apparatus 80,the metric information collector 82 might request, receive, or otherwiseobtain metric information that was provided to the PCC by one or morePCEs. In this case, the PCC interacts with the PCE(s), and the metricinformation collector 82 collects metric information associated withvirtual connections without actually communicating with the PCE(s). Themetric information collector 82 and the PCC could potentially beconfigured to implement a request/response scheme according to which themetric information collector requests metric information from the PCC.If the PCC stores metric information received from PCEs in anothermemory (not shown), then the metric information collector 82 couldcollect, from the metric information that is received from the PCE(s)and stored by the PCC, metric information that is currently needed forpath selection. In some embodiments, the functions of the metricinformation collector 82 may be integrated within a PCC.

Other mechanisms for collecting metric information from PCEs may also beor become apparent to those skilled in the art.

Using a collection mechanism, or possibly multiple collectionmechanisms, the metric information collector 82 collects metricinformation associated with different candidate routes over which avirtual connection toward a destination can be established. Thecollected metric information is indicative of one or more route metrics.Cost is one example of a metric for which metric information could becollected in some embodiments. Those skilled in the art will also befamiliar with other metrics, illustratively Traffic Engineering (TE)metrics, that might be used to describe, rank, or otherwisedifferentiate between different possible routes that may be used for avirtual connection. Other examples of metrics include, but are in no waylimited to, cumulative delay to reach the destination from the sourceover a given route or maximum/minimum available bandwidth (bandwidthbottleneck) remaining after establishing the virtual connection over theroute. Further metrics to which the presently disclosed techniques couldbe applied may be or become apparent to those skilled in the art.

The metric information collector 82 may also perform such functions asmetric information processing. For example, if the metric informationcollector 82 or another component such as a PCC of the routing apparatus80 interacts directly with multiple PCEs when multi-domain routes are tobe computed, the metric information collector 82 may combine metricinformation for multiple path segments to determine a total end-to-endmetric for each path. Collected metric information may be stored in thememory 84 in the form in which it is collected and/or in a processedform.

The present invention is in no way dependent upon any particularalgorithm used by route computation elements to compute routes ormetrics. Many such algorithms will be known to those skilled in the art,and the techniques disclosed herein may also be applicable to new routeor path computation algorithms that are subsequently developed.

As noted above, a routing apparatus that interacts with one or moreremote route computation elements typically relies on the routecomputation element(s) to make route optimization decisions. Inaccordance with an embodiment of the invention, however, the selectionmodule 88 at the routing apparatus 80 is operable to select a route fora virtual connection toward a particular destination based on the metricinformation collected by the metric information collector 82 fordifferent computed routes for the same virtual connection. The selectionmodule 88 may use a metric comparison function, or a more complexfunction, to select a particular computed route from multiple computedroutes for which metric information has been collected. A comparisonfunction would be suitable for selecting a least cost path, for example.Multiple metrics might be taken into account by the selection module 88,for instance, to implement a weighted combination of cost and delaymetrics.

The particular selection function used by the selection module 88 may bepredefined or configurable, illustratively through a Command LineInterface (CLI) or other interface of an NMS or other terminal.

It should be noted that this type of distributed route selectioncapability might be used, for example, to enable a routing apparatus toimplement a different optimal route selection mechanism than a PCE,and/or to apply a “margin” to route optimality. A PCE might apply oneset of cost criteria in its path computation, for instance, whereas aselection module 88 at a routing apparatus could then apply differentcriteria to the same cost information to reach a different optimal pathselection. In this case, the routing apparatus applies a different routeselection mechanism than the PCE. If an attempt is being made tore-optimize an existing virtual connection to a destination, then theselection module 88 might only re-route the virtual connection if acertain margin of improvement would be met. This type of function istypically not supported at least in PCE-based systems.

A route selection made by the selection module 88 may be an initialselection for a virtual connection toward a destination. In this case,the route is selected for a virtual connection for initiallyestablishing communication traffic transfer between the routingapparatus and the destination. The selection module 88 may also orinstead select a route for re-optimizing a virtual connection. After avirtual connection has been established at the routing apparatus 80toward a destination, the metric information collector 82 may collectmetric information for alternate routes for the virtual connection. Theselection function that was used by the selection module 88 to selectthe route for the existing virtual connection, or potentially adifferent selection function, is used to determine whether the existingvirtual connection or a virtual connection over an alternate route,should be used for subsequent communications with the destination. Thisdecision may in some embodiments take into account a minimum margin ofimprovement, as discussed above.

The virtual connection for which a route is selected by the selectionmodule 88 may be a complete virtual connection between the routingapparatus 80 and another routing apparatus at which a destination isreachable, for example. It should be appreciated, however, that thevirtual connection may be a segment of a multi-segment virtualconnection.

A route computation element such as a PCE may provide informationindicative of the different computed routes, in addition to metricinformation for each computed route. This information may also be storedin the memory 84 or a separate memory area or device. At least selectedroute information is also provided to or otherwise obtained by therouting module 87. For example, the selection module 88 may provideselected route information to the routing module 87 in some embodiments.A route identifier or other indicator using which the routing module 87can access stored route information for the selected route in a memorysuch as 84 may instead be provided to the routing module by theselection module 88.

The routing module 87 is operable to cause a virtual connection to beestablished over a selected route. This may involve exchanging controlsignalling with other routing apparatus through T-LDP sessions or otherforms of signalling adjacencies, for example. Control signalling may behandled by the routing module 87 itself, or by signalling components orapparatus associated with the routing apparatus 80.

Embodiments of the invention are applicable to other than PCE-basedsystems. Metric information collection, and possibly other functionssuch as route computation, need not necessarily involve remote routecomputation elements. The routing module 87 itself or another componentof the routing apparatus 80, for example, may be operable to determinemultiple different possible routes for a virtual connection using arouting table for instance. The routing apparatus 80 may similarly havea more active role in metric information collection.

Whether routes are computed locally at a routing apparatus or by remoteroute computation elements, metric information for different routes canpotentially be collected during establishment of virtual connectionsover those routes. The metric information collector 82 may extractmetric information from control signalling exchanged between the routingapparatus 80 and other routing apparatus during connection setup. Anexample of this type of metric collection mechanism is described belowwith reference to FIG. 7. The metric information collector 82 maycommand or otherwise cause the routing module 87 to initiate virtualconnections over different routes, and then collect metric informationfrom the resultant control signalling, for example. Although the metricinformation collector 82 need not necessarily have an active role in theactual exchange of control signalling during virtual connectionestablishment, it may directly or indirectly monitor the controlsignalling, such as by passively “listening” for control signalling orparticipating in the transfer of control signalling, for metricinformation.

These metric information collection mechanisms, and possibly others, maybe applied to optimization of PWs, for example. In this case, the metricinformation collector 82 collects metric information respectivelyassociated with a plurality of different routes over which PWs forexchanging communication traffic between the routing apparatus 80 and adestination can be established. In an optimization scenario, thedifferent PW routes include a currently selected PW route for a PW thathas been established toward the destination, as well as other routes.The selection module 88 selects either the currently selected PW routeor another one of the different PW routes for a PW for subsequentlyexchanging communication traffic with the destination. This selection isbased on the metric information respectively associated with theplurality of different PW routes.

If metric information is collected from control signalling that isexchanged during PW establishment, the routing module 87 may be furtheroperable to cause each established PW, having a PW route other than thePW route selected by the selection module 88 for subsequently exchangingcommunication traffic with the destination, to be released. The routingmodule 87 may itself release each PW having a non-selected PW route orcooperate with other components such as signalling apparatus to releaseeach such PW.

FIG. 5 is a flow diagram of a method according to another embodiment ofthe invention. The method 90 is performed at a routing apparatus, andinvolves collecting, at 92, metric information associated with aplurality of different routes for a virtual connection toward adestination. In one embodiment, the metric information is collected frommetric information generated by at least one remote route computationelement that is capable of computing routes for virtual connectionsbetween the routing apparatus and other routing apparatus over anunderlying communication system. Metric information may also or insteadbe collected through other mechanisms, such as from control signalling.

At 94, a determination is made as to whether a current route is optimal.This determination might not be made in all embodiments, since routere-optimization is predicated on an existing virtual connection. A newroute, or an initial route in some embodiments, for a virtual connectiontoward the destination is selected at 96 based on the collected metricinformation. In the event that a currently selected route is determinedto be optimal, or more generally, if it is determined at 94 that noother route is superior to the currently selected route in respect of aroute selection function, then the currently selected route remainsselected. Metric information collection at 92 may then continue or berepeated at a later time for another re-optimization attempt.

Release of a virtual connection or route at 98 is also specific toparticular embodiments of the invention. Virtual connections overnon-selected routes would be released at 98, for example, if metricinformation is collected at 92 during virtual connection establishment,or if the method 90 is used to re-optimize a virtual connection route.

It should be appreciated that the method 90 is illustrative of oneembodiment of the invention. Variations of the method 90 are alsocontemplated. For example, collecting metric information at 92 mayinvolve receiving the metric information from one or more remote routecomputation elements.

In general, methods according to other embodiments may include further,fewer, or different operations, performed in a similar or differentorder, than shown in FIG. 5. Examples of such operations, and variousways in which operations may be performed, will be apparent from theforegoing description of FIGS. 1 to 4. Further variations of the method90 may be or become apparent to those skilled in the art.

Embodiments of the invention have been described above primarily in thecontext of apparatus and systems. However, aspects of the invention mayalso involve the use of data structures for instance. FIG. 6 is a blockdiagram of an example data structure for carrying metric information incontrol signalling. FIG. 7 is a block diagram of another example datastructure for transferring metric information to routing apparatus froma route computation element. A data structure may, in addition to beingencoded, modulated, or otherwise incorporated into a signal or otherform of physical carrier for distribution, also be stored in a linkstate database or other data store.

The data structures shown in FIGS. 6 and 7 may be used to specify thecost of a virtual connection in the form of a TE LSP. A COST object asshown in FIG. 6, for example, could be carried within an RSVP message soas to record a TE LSP cost during LSP establishment, and the object asshown in FIG. 7 might be included within a PCEP message so as to provideone or more metrics associated with a computed path to a PCC.

Route or path costs are described in detail below solely for thepurposes of illustration. Cost is one example of a metric that may beused in some embodiments of the present invention. Other metrics mayalso or instead be collected and used in a substantially similar manner.The present invention is in no way limited to cost or any other specificmetric.

There are various circumstances in which the Label Switching Router(LSR) at the head end of a TE LSP does not have the ability to determinethe total cost of a computed TE LSP. Inter-domain TE LSP computation mayuse a conventional approach, where each segment is computed by boundarynodes. Consequently, although the head-end LSR can determine thecomputed path, it cannot determine the total path cost. Another exampleis when a PCE-based path computation is used to compute TE LSP. In sucha case, the head-end LSR (acting as a PCC) may request the PCE toprovide the cost of a computed path.

These cases illustrate scenarios in which a new object to be carriedwithin an RSVP message or within a path computation reply message mightbe particularly useful. Although cost is described herein, thesetechniques could also be applied to other path or route metrics.

According to one possible implementation, a head-end LSR collects thecost of a TE LSP by including in an RSVP Path message an LSP-ATTRIBUTESobject with Attribute Flags TLV having a “Path cost requested” flag set.The TLV is passed transparently towards a tail-end LSR. When thetail-end LSR receives the RSVP Path message, the LSR places in thecorresponding RSVP Resv message an RRO Attributes Subobject with a “Pathcost” flag set inside the RRO. The cost value inside the COST object isinitially set to 0.

Every LSR that the Resv message traverses increments the cost valueinside the COST Object with the cost of its downstream link and adds tothe RRO an RRO Attributes Subobject with the “Path cost” flag set. Theabsence of the RRO Attributes Subobject with the “Request path cost”flag set for any hop indicates to the head-end LSR that the accumulatedpath cost does not represent the total path cost.

The COST object shown in FIG. 6 is thus an optional object carried inRSVP Resv messages to collect the cost of a TE LSP. The object is addedby a tail-end LSR that supports path cost accumulation when such anaccumulation was requested by the head-end LSR, and is updated by LSRsthat support the object and path cost accumulation for a given TE LSP.LSRs that do not understand the object or have elected not toparticipate in path cost accumulation for this LSP pass this objectunchanged in the Resv message they generate.

The example format of the COST object for RSVP, as shown, includes aLength field specifying the length of the object in bytes, a Class-Numfield including a class number, a C-Type field, and a Cost object body.The Class-Num field includes a value for ensuring that LSRs that do notrecognize the object pass it on transparently. The present invention isnot restricted to any specific value for this field. A Class-Num valuemay be subject to approval by an authority such as the Internet AssignedNumbers Authority or a designated expert, for example.

A C-Type value, which may also be subject to such approval, indicates atype of the COST object.

Cost information is specified in the Cost object body, illustratively asa 32-bit unsigned integer specifying the cost associated with a computedpath.

Collection of path costs through RSVP signalling, as described brieflyabove, may be enabled by a new flag to allow a head-end LSR to requestpath cost accumulation and to allow LSRs to report to the head-end LSRwhether the cost accumulation took place. An Attribute Flags TLV withthe “Path cost” flag set may be included by the head-end LSR in theLSP_ATTRIBUTES Object in a Path message to request path costaccumulation. An RRO Attributes Subobject with the “Path cost” flag setis included by every LSR in the RRO in a Resv message to indicate thatthe LSR performed the path accumulation. The COST object is alsoincluded by a tail-end LSR in the Resv message to accumulate TE-LSP pathcost.

In terms of processing, the normal rules for processing ofLSP_ATTRIBUTES Object and RRO Attributes Subobject may substantiallyapply to implementations that support path cost accumulation, with thefollowing additional details in some embodiments.

A head-end LSR may include an Attributes TLV with “Path cost” flag setwithin an LSP-ATTRIBUTES object in an RSVP Path message to request pathcost accumulation. Each LSR along a path extracts the path cost from theCOST object in a corresponding RSVP Resv message and increments it byits downstream link to obtain the current path cost for the TE LSP. Thehead-end LSR examines the RRO to determine whether the cost accumulatedis of the entire path, based on RRO Attributes Subobjects added by eachnode along the LSP path.

Intermediate transit LSRs do not modify the “Path cost” flag set withinthe Attributes TLV within LSP-ATTRIBUTES in a received RSVP Path messagebut should include in the corresponding RSVP Resv message an RROAttributes Subobject with the “Path cost” flag set and increment theCost value in the COST object with the cost of its downstream link, ifit supports path cost accumulation. An intermediate LSR does not updatethe corresponding RSVP Resv message RRO Attributes Subobject with the“Path cost” flag set and passes the COST object unchanged if it does notsupport path cost accumulation or if it elects not to provide path costaccumulation for this LSP setup.

A tail-end LSR, upon receiving an RSVP Path message including anAttributes TLV with a “Path cost” flag set within the LSP-ATTRIBUTES,should include in the corresponding RSVP Resv message an RRO AttributesSubobject with the “Path cost” flag set and a COST object with a costvalue set to 0, if it supports path cost accumulation. Otherwise, thetail-end LSR does not include in the RSVP Resv message an RRO AttributesSubobject with the “Path cost” flag set and does not include a COSTobject, such as if it does not support path cost accumulation or if itelects not to provide path accumulation for this LSP setup.

When RSVP Fast Reroute is employed along the path, normal general rulesfor failure processing substantially apply, although an updated ResvMessage sent by a Point of Local Repair (PLR) will include theLSP-ATTRIBUTES, COST, and RRO objects of the path being activated andthe newly collected cost would need to be updated.

In some cases, it may be desirable for a PCC to know the cost ofcomputed paths returned by a PCE. A mechanism to request such a cost isalready defined in the PCEP. To return the cost to the PCC uponsuccessful path computation, the PCE includes in the PCRep message thecost of a computed path, and possibly each of multiple computed paths,using a COST object.

An example of a PCEP COST object is shown in FIG. 7. When carried aspart of a PCRep message, the COST object may be preceded by the 32-bitPCEP common object header.

The Object-Class header field and the Object-Type (OT) fields includevalues that would allow a PCEP object to be identified as a COST objectand, like the values of header fields shown in FIG. 6, may be subject toapproval. The present invention is not restricted to any particularvalues.

These and the other header fields are described in detail in theabove-referenced PCEP Internet-Draft document. The Reserved (Res) fieldincludes two flag bits, which in current implementations of PCEP are setto 0. The P field includes a 1-bit Processing-Rule flag, which whencleared specifies that an object is optional. A 1-bit Ignore flag in theI field is used to indicate to a PCC whether or not an optional objectwas processed. The Object Length field includes a value indicating thetotal object length, including the header, in bytes.

The Cost object body may as above include a 32-bit unsigned integerindicating path cost.

The example PCEP COST object of FIG. 7 is an optional object that may becarried as part of a PCRep message. The format of the <path> elementreturned as part of a PCRep message may be modified as follows toaccount for the COST object in one embodiment:

<path>::=<RP> [<NO-PATH>] [<ero-list>] [<LSPA>] [<BANDWIDTH>] [<DELAY>][<XRO>] [<IRO>] [<COST>]

The COST object shown in FIG. 7 may be carried within PCRep messages. Assuch, elements of PCEP procedure as applicable to optional objects thatare part of those messages may substantially apply to the COST object. APCE should return the total cost of a computed path when requested to doso in a PCReq message. If the PCE decides not to return the cost asrequested by a PCC, the Cost value inside the COST object should be setto 0.

Another possible option for collection of metric information in aPCE-based system is also proposed in the above-referenced PCEPInternet-Draft document. As described in detail in that document, aMETRIC object may be inserted by a PCE in a PCRep message so as toprovide the cost and/or delay for a computed path. An Object-Class,Object-Type, and/or other fields may be used to distinguish an object asa METRIC object and to specify how such an object is to be handled.Three metric types are currently defined, namely IGP metric, TE metric,and Hop Counts, although other types may subsequently be developed.

Based on the examples above, those skilled in the art will be enabled toimplement path or route cost collection mechanisms for other protocolsthan RSVP and PCEP. The above examples further illustrate that any ofvarious implementations may be used even in these protocols. Theabove-referenced PCEP Internet-Drafts, for instance, describes two typesof objects that could potentially be used by PCEs to distributed metricinformation.

Embodiments of the invention as disclosed herein may allow optimalnetwork utilization end-to-end, which in turn may improve networkrobustness, and/or decrease bandwidth utilization across a network byminimizing the number of links used to provide end-to-end services.

Network robustness may also be improved by making PW establishmentdynamic and less error prone to human configuration errors.

Operating expenditures may thereby be reduced.

What has been described is merely illustrative of the application ofprinciples of embodiments of the invention. Other arrangements andmethods can be implemented by those skilled in the art without departingfrom the scope of the present invention.

For example, although RSVP is discussed in detail herein, similartechniques may apply to other protocols. Other disclosed illustrativeexamples should similarly be interpreted in a non-limiting manner. A PWis one type of virtual connection that can be established forcommunication traffic transfer. The techniques disclosed herein,however, may also be applicable to other types of virtual connections.

The divisions of functions shown in the drawings and described above arealso intended to be illustrative and non-limiting. Embodiments of theinvention may be implemented using further, fewer, or differentfunctional elements than considered above.

In addition, although described primarily in the context of methods andsystems, other implementations of the invention are contemplated, asinstructions stored on a computer-readable medium, for example.

We claim:
 1. A communication traffic routing apparatus comprising: a metric information collector operable to collect, from metric information generated by at least one remote route computation element that is capable of computing routes for virtual connections between the routing apparatus and other routing apparatus over an underlying communication system, metric information associated with a plurality of different computed routes for a virtual connection with a destination; and a selection module operatively coupled to the metric information collector and operable to select, from the different computed routes, based on the collected metric information, a route for a virtual connection with the destination, the different computed routes comprising a currently selected route of an existing virtual connection that has been established with the destination; and the selection module being operable to re-optimize the currently selected route by selecting, based on the collected metric information, between the currently selected route and another one of the different computed routes that provides at least a minimum margin of improvement over the currently selected route.
 2. The routing apparatus of claim 1, further comprising: an interface operatively coupled to the metric information collector and operable to enable the routing apparatus to communicate with the at least one remote route computation element, wherein the metric information collector is operable to collect metric information by receiving the metric information from the at least one remote route computation element through the interface.
 3. The routing apparatus of claim 2, wherein the metric information collector is further operable to receive through the interface, from any of the at least one remote route computation element, information indicative of each of the different computed routes.
 4. The routing apparatus of claim 1, wherein each of the at least one remote route computation element comprises a Path Computation Element (PCE) for computing Label Switched Paths (LSPs), and wherein the metric information collector comprises a Path Computation Client (PCC).
 5. The routing apparatus of claim 1, wherein the virtual connections comprise PseudoWires.
 6. The routing apparatus of claim 1, wherein at least one of the virtual connections comprises a multi-segment virtual connection having a plurality of segments.
 7. The routing apparatus of claim 1, wherein the metric information associated with each computed route of the plurality of different computed routes comprises information indicative of a route cost.
 8. A method comprising: collecting at a routing apparatus, from metric information generated by at least one remote route computation element that is capable of computing routes for virtual connections between the routing apparatus and other routing apparatus over an underlying communication system, metric information associated with a plurality of different computed routes for a virtual connection with a destination; and selecting at the routing apparatus, from the different computed routes, based on the collected metric information, a route for a virtual connection with the destination, the different computed routes comprising a currently selected route of an existing virtual connection that has been established with the destination; and the selecting comprising re-optimizing the currently selected route by selecting, based on the collected metric information, between the currently selected route and another one of the different computed routes that provides at least a minimum margin of improvement over the currently selected route.
 9. The method of claim 8, wherein collecting comprises receiving the metric information from the at least one remote route computation element.
 10. The method of claim 8, wherein each of the at least one remote route computation element comprises a Path Computation Element (PCE) for computing Label Switched Paths (LSPs), and wherein receiving comprises receiving the metric information at a Path Computation Client (PCC) of the routing apparatus.
 11. The method of claim 8, wherein the metric information associated with each computed route of the plurality of different computed routes comprises information indicative of at least one of: a route cost, cumulative delay to reach the destination from the routing apparatus over each computed route, and an amount of available bandwidth on each computed route after establishing the virtual connection over the computed route.
 12. A communication traffic routing apparatus comprising: a metric information collector operable to collect metric information respectively associated with a plurality of different routes over which PseudoWires (PWs) for exchanging communication traffic between the routing apparatus and a destination can be established, the different PW routes comprising a currently selected PW route of an existing PW that has been established with the destination; and a selection module operatively coupled to the metric information collector and operable to re-optimize the currently selected PW route by selecting, based on the collected metric information, between the currently selected PW route and another one of the different PW routes that provides at least a minimum margin of improvement over the currently selected PW route.
 13. The routing apparatus of claim 12, further comprising: an interface operatively coupled to the metric information collector and operable to enable the metric information collector to communicate with a remote route computation element, the remote route computation element being capable of computing a PW route of the plurality of different PW routes, wherein the metric information collector is operable to collect metric information by receiving through the interface, from the remote route computation element, metric information associated with the PW route that the remote route computation element is capable of computing.
 14. The routing apparatus of claim 12, further comprising: a routing module operatively coupled to the metric information collector and operable to cause any of the PWs to be established, wherein the metric information collector is further operable to collect metric information associated with a PW route of each of the PWs during establishment of the PWs.
 15. The routing apparatus of claim 14, wherein the routing module is further operable to cause each established PW having a PW route other than the PW route selected by the selection module for subsequently exchanging communication traffic with the destination to be released.
 16. The routing apparatus of claim 14, wherein each of the PWs is established through control signalling, and wherein the metric information collector is operable to collect, from the control signalling, the metric information associated with the PW route of each of the PWs.
 17. A method comprising: collecting at a routing apparatus metric information respectively associated with a plurality of different routes over which PseudoWires (PWs) for exchanging communication traffic between the routing apparatus and a destination can be established, the different PW routes comprising a currently selected PW route of an existing PW that has been established with the destination; and re-optimizing the currently selected PW route by selecting at the routing apparatus, based on the collected metric information, between the currently selected PW route and another one of the different PW routes that provides at least a minimum margin of improvement over the currently selected PW route.
 18. The method of claim 17, wherein collecting comprises receiving, from a remote route computation element that is capable of computing a PW route of the plurality of different PW routes, metric information associated with the PW route.
 19. The method of claim 17, further comprising: exchanging control signalling with other routing apparatus to establish at least one PW having a PW route other than the currently selected PW route, wherein collecting comprises collecting, from the control signalling, metric information associated with the PW route of each of the at least one of the PWs.
 20. The routing apparatus of claim 1, wherein the metric information associated with each computed route of the plurality of different computed routes comprises information indicative of cumulative delay to reach the destination from the routing apparatus over each computed route.
 21. The routing apparatus of claim 1, wherein the metric information associated with each computed route of the plurality of different computed routes comprises information indicative of an amount of available bandwidth on each computed route after establishing the virtual connection over the computed route.
 22. The routing apparatus of claim 1, wherein the selection module is operable to select the route for the virtual connection with the destination based on a combination of metric information for different metrics.
 23. The routing apparatus of claim 22, wherein the combination of metric information comprises a weighted combination.
 24. The routing apparatus of claim 1, wherein the at least one remote route computation element comprises a plurality of remote route computation elements in respective different communication system administrative boundaries.
 25. The routing apparatus of claim 1, wherein the minimum margin of improvement comprises a minimum margin of improvement in a metric for which the collected metric information is collected. 